The present invention relates to computer networks and, more particularly, to a network appliance that monitor parameters (e.g., related to their own and/or a network""s performance). A major objective of the present invention is to facilitate fault handling in a computer network.
Computer networks allow computer users to communicate, collaborate, and share resources. While there are peer-to-peer computer networks, most sophisticated networks use network infrastructure appliances, e.g., hubs, switches, and routers, to manage communication between end-node appliances, e.g., computers, printers, modems, instrumentation, etc. A typical network infrastructure appliance includes multiple ports, each of which can be coupled to an end-node appliance or another network appliance. Networked end-node appliances communicate with each other through the network infrastructure appliances.
Just as individuals rely increasingly on computers for getting their work done, corporations rely increasingly on networks for getting their personnel to work cooperatively. When a network fails, group efforts grind to a halt, as do individual efforts relying on network resources. To a lesser degree, productivity is adversely affected when network performance is impaired. Accordingly, maintaining a network working and performing at optimal levels is highly desirable, if not critical. Unfortunately, such maintenance can also be quite difficult.
Many network appliances monitor performance-related parameters and, when the values of these parameters fail to meet certain criteria, transmit a notification to that effect over the network. For example, network infrastructure appliances often include counters for counting certain network related events (e.g., packet collisions); when a count or combination of counts indicates a problem, a xe2x80x9ctrapxe2x80x9d can be transmitted in accordance with a Simple Network Management Protocol (SNMP). For another example, a printer can monitor its components; when a problem is detected, the printer can transmit an xe2x80x9cinformxe2x80x9d in accordance with a Desktop Management Interface (DMI) protocol.
The various notifications can be received by a network management station, such as a computer devoted at least in part to network management. The network management station can present the notifications to a human administrator, who can determine whether or not corrective action is required and who can undertake corrective action if required.
In many cases, the information included in the notification is not comprehensive. Transmitting all pertinent information regarding triggering events might unduly burden a network; also, the pertinence of the information might wane if the administrator does not address the notification immediately. Accordingly, a concise notification is often a prelude to a more detailed investigation by the administrator.
When the more detailed information is desired, the administrator can request (through the network management station) that the network appliance transmit additional information. If the detailed information is presented in xe2x80x9crawxe2x80x9d form, considerable demands are made on the expertise of the administrator in interpreting the data to diagnose the problem and in evaluating alternative courses of action. These demands are compounded in the common case where the network includes many appliance types, each with its own relevant parameters and alternative corrective actions. Since the individual trigger events might occur infrequently, an administrator might have to refer to the appropriate appliance manual each time a triggering-event notification is received.
The burden on the administrator can be relieved considerably by including the expertise into the network management station. The network management station can include a characterization of each appliance type on the network. The characterization can be used in interpreting appliance data and in suggesting alternative courses of action.
While such a solution appears feasible in a network in which all appliances (including the network management station) are from a single vendor, it is less workable where there are appliances from multiple vendors involved. Furthermore, when a new appliance type is added to the network, the network management station would have to be updated (e.g., through a patch or module added to the network management program running on the network management station). This might mean that each new appliance would have to be sold with program updates for each network administration program.
Thus, however they are allocated between the administrator and the network management station, the tasks of notification data interpretation and of determining responses can be unduly burdensome. What is needed is a network administration system, which minimizes the burden on the network administrator while allowing ready expandability of a network.
The present invention provides a network appliance that incorporates both asynchronous notification of xe2x80x9ctriggeringxe2x80x9d events and a server that conforms to an interactive network transfer protocol such as the HyperText Transfer Protocol (HTTP). When the network appliance detects a triggering event calling for notification to the network management station, it issues the notification and specifies therein a xe2x80x9cUniform Resource Locatorxe2x80x9d (URL) including a xe2x80x9cUniform Resource Identifierxe2x80x9d (URI) pointing to a network location on the server.
Complementarily, the present invention provides for a variety of ways for a network management station to handle the notification. For example, it can simply inform a user of the URL by displaying it in text form on a display. In this case, a user can copy the URL to a web browser (or other HTTP-enabled program), and access the location characterizing the triggering event. Preferably, the network management station either incorporates or interfaces with a browser so that a simple point and click operation accesses the network appliance server. In this vein, the network management program can present the URL as a hypertext link, as a button, or as a menu selection. Activating the link, button or menu item can access the URL directly or, alternatively, call a browser that in turn accesses the URL.
When the URL is accessed, the network appliance server can provide the information relating to the event in conformance with the HTTP standard. Preferably, the information is presented on a web page that is a subpage of a home page associated with the server. Also preferably, the subpage can include active display elements (hypertext links, buttons, and/or menu items) that can initiate network management actions appropriate to the triggering event. These actions can involve changing the state of the network appliance (e.g., by resetting counters) for further diagnosis or for ignoring the event. To conserve memory on the appliance, the subpage can be generated after the URL is received (rather than when the notification is transmitted).
Unlike most appliances with web servers, the present invention provides for efficient access to asynchronous (not initiated by the user) events at the server. For the most part, the web interface is operated by user commands; in other words, the web interface mostly provides for synchronous communication from the server and the user. Combining the web. interface with a network or appliance management protocol allows asynchronous network events to initiate interaction with the web server on the network appliance. In general, access to appliances is through the home page. It is often necessary to navigate to various subpages to find information of interest. By providing the URI (the part of the URL indicating the location within a server where certain information can be found), the present invention avoids the tedium of navigating through a web interface.
An interactive-network-transfer protocol is a network protocol in which: 1) a client can transmit a command to a server; 2) the server responds to the command by transmitting (generating first if required) data including active elements to the client; 3) the client displays the data including representations of the active elements; 4) activation of active elements by a client user causes data to be transmitted to the server; and 5) the server, upon receiving data transmitted in response to activation of an active element, performs some action, typically involving the transmission of data to the client so that the client display is modified. HTTP is the most widely familiar interactive-network-transfer protocol. However, the invention can be applied in the context of alternative interactive-network-transfer protocols.
One advantage of the present invention is that it provides a familiar interface for a network administrator to manage a network. For example, the World Wide Web is not only a standard interface for the Internet, but also for intranets. Also, there is a trend to provide network appliances with web interfaces. Thus, minimal training is required for a network administrator to learn the interface.
A second advantage of the invention, which is both subtle and surprising, is that it obviates the need to update the network management software as new types of network appliances are incorporated into the network. All the information regarding a triggering event and the options for handling it are handled by the web server on the network appliance. The network management program on the network management station does not need to have a characterization of each network appliance. The only requirement is that the network management program be able to communicate the URL associated with the triggering event to the user or to the user""s browser.
A third advantage is that effort on the user""s part in accessing information about the triggering event is minimized. In a typical realization of the invention, one point-and-click operation is required to access the relevant page of the appliance server; one more point-and-click is often sufficient as a response to the triggering event.